service processing method and service processing device

专利摘要:
Embodiments of the present invention disclose a processing and service consensus process and device. In the method, a first trust protocol node includes a plurality of servers. the first trust protocol node may receive a service request sent by a client and store the service request, by using the plurality of included servers, obtain at least one service request from a service memory comprised in the first service node. trust protocol by using one server on the plurality of servers to obtain a preprocessing block and sending the preprocessing block to each second trust protocol node in a consensus network through the server usage to perform service consensus on the preprocessing block by using each second trusted protocol node. it can be ensured that the first trust protocol node is available as long as one server on the plurality of servers comprised in the first trust protocol node is available. therefore, the stability of the first trust protocol node in the consensus network is improved.
公开号:BR112019013204A2
申请号:R112019013204
申请日:2018-03-26
公开日:2019-12-10
发明作者:Li Yi
申请人:Alibaba Group Holding Ltd；
IPC主号:

专利说明:

"METHOD FOR PROCESSING SERVICES AND DEVICE FOR PROCESSING SERVICES"
Field of the invention [001] The present invention relates to the field of computer technologies and, in particular, to a method and device of processing and consensus of service.
Background of the Invention [002] With the continued development of computer technologies, reliable protocol technology is more widely applied. In addition to implementing effective data recording, people also use trusted protocol technology to provide a new idea for implementing some services.
[003] Currently, performing service processing through the use of trusted protocol technology basically includes two processes: service processing process and service consensus process. In the service processing process, a trust protocol node receives a service request sent by a user and stores the service request in a service memory of the trust protocol node. In addition, the trust protocol node transmits the service request to other trust protocol nodes in a consensus network, so that the other trust protocol nodes store the service request in a service memory corresponding to the others trust protocol nodes after receiving the service request.
[004] In the service consensus process, a trust protocol node obtains a certain number of service requests from a service memory corresponding to the trust protocol node and processes the service requests obtained to obtain a pre block
Petition 870190058824, dated 06/25/2019, p. 138/192
2/50 processing. The trust protocol node then transmits the preprocessing block to other trust protocol nodes in a consensus network, so that the other trust protocol nodes perform service consensus in the preprocessing block afterwards. receiving the pre-processing block.
[005] One can learn from the two processes described previously that the process of a trust protocol service can be effectively completed only through close cooperation between trust protocol nodes in the consensus network. However, in practice, a trusted protocol node is generally restricted by a single server, which causes relatively low stability. Since an exception, a program restart, etc., occurs on the server, the trust protocol node is not available, which affects the stability of the entire consensus network and affects the process of a trust protocol service . In addition, the software and hardware resources of a single server are very limited, which causes relatively low efficiency when the trusted protocol node performs service processing.
Brief Description of the Invention [006] Embodiments of the present invention provide a method of processing services, in order to solve problems in existing technology that the stability is relatively weak and the efficiency of the service processing is relatively weak when a node trust protocol performs service processing.
[007] An embodiment of the present invention provides a method of processing services, including the following: receiving, through a first trust protocol node and, through the use of a server comprised in the first trust protocol node, a service request sent by a client, where the first trust protocol node
Petition 870190058824, dated 06/25/2019, p. 139/192
3/50 includes a plurality of servers and at least one service memory; store the service request in the service memory comprised in the first trust protocol node; and send the service request to each second trust protocol node in a consensus network, so that each second trust protocol node stores the service request in a service memory comprised in the second trust protocol node after receiving the service request, wherein the second trusted protocol node includes a plurality of servers and at least one service memory.
[008] Embodiments of the present invention provide a service processing device in order to solve problems in existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[009] An embodiment of the present invention provides a service processing device, including the following: a receiving module, configured to receive a service request sent by a customer; a storage module, configured to store the service request in a service memory corresponding to the service processing device; and a sending module, configured to send the service request to each second trust protocol node in a consensus network, so that each second trust protocol node stores the service request in a service memory comprised in the second trust protocol node after receiving the service request, wherein the second trust protocol node includes a plurality of servers and at least one service memory.
[010] Embodiments of the present invention provide a method of processing services in order to solve problems in
Petition 870190058824, dated 06/25/2019, p. 140/192
4/50 existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[011] An embodiment of the present invention provides a method of processing services, including the following: receiving, through a second trust protocol node, through the use of a server comprised in the second trust protocol node, a service request sent by a first trust protocol node, where the second trust protocol node includes a plurality of servers and at least one service memory, and the first trust protocol node includes a plurality of servers and at at least one service memory; and storing the service request in the service memory comprised in the second trust protocol node.
[012] Embodiments of the present invention provide a service processing device in order to solve problems in existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[013] An embodiment of the present invention provides a service processing device, including the following: a request receiving module, configured to receive a service request sent by a first trusted protocol node, in which the first trust protocol node includes a plurality of servers and at least one service memory; and a request storage module, configured to store the service request in a service memory corresponding to the device.
[014] Embodiments of the present invention provide a method of processing services in order to solve problems in
Petition 870190058824, dated 06/25/2019, p. 141/192
5/50 existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[015] An embodiment of the present invention provides a method of processing services, including the following: receiving, via a customer, service information entered by a user; generate a corresponding service request based on the service information; and sending the service request to a server comprised of a first trust protocol node, so that the first trust protocol node stores the service request received in a service memory comprised in the first trust protocol node; and sending the service request to each second trust protocol node in a consensus network, where the first trust protocol node includes a plurality of servers and at least one service memory, and the second trust protocol node includes a plurality of servers and at least one service memory.
[016] Embodiments of the present invention provide a service processing device, in order to solve problems in existing technology that the stability is relatively weak and the efficiency of service processing is relatively weak when a trusted protocol node performs service processing.
[017] An embodiment of the present invention provides a service processing device, including the following: an information receiving module, configured to receive service information entered by a user; a request generation module, configured to generate a corresponding service request based on the service information; and a sending module, configured to send the service request to a server comprised on a first node
Petition 870190058824, dated 06/25/2019, p. 142/192
6/50 trust protocol, so that the first trust protocol node stores the service request received in a service memory comprised in the first trust protocol node; and sending the service request to each second trust protocol node in a consensus network, where the first trust protocol node includes a plurality of servers and at least one service memory, and the second trust protocol node includes a plurality of servers and at least one service memory.
[018] Embodiments of the present invention provide a service consensus method, in order to resolve problems in existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[019] An embodiment of the present invention provides a service consensus method, including the following: selecting, through a first trust protocol node, a server from a plurality of servers comprised in the first trust protocol node trust, where the first trust protocol node includes the plurality of servers and at least one service memory; obtain at least one service request from the service memory included in the first trust protocol node, using the selected server; and package at least one service request in a preprocessing block, using the selected server and send the preprocessing block to each second trust protocol node in a consensus network, so that each second trust protocol realizes service consensus in the preprocessing block, in which the second trust protocol node includes a plurality of servers and at least one service memory.
Petition 870190058824, dated 06/25/2019, p. 143/192
7/50 [020] Embodiments of the present invention provide a service consensus device in order to solve problems in existing technology that stability is relatively low and service processing efficiency is relatively weak when a Trust protocol performs service processing.
[021] An embodiment of the present invention provides a service consensus device, including the following: a request acquisition module, configured to obtain at least one service request from a service memory corresponding to the device; and a sending module, configured to package at least one service request in a preprocessing block, and send the preprocessing block to each second trust protocol node in a consensus network, so that each second node trust protocol realizes service consensus in the pre-processing block, where the second trust protocol node includes a plurality of servers and at least one service memory.
[022] Embodiments of the present invention provide a service consensus device in order to resolve problems in existing technology that stability is relatively low and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[023] An embodiment of the present invention provides a service consensus device, including the following: a selection module, configured to select a server from a plurality of servers comprised in a first trusted protocol node, in that the first trust protocol node includes the plurality of servers and at least one service memory.
[024] Embodiments of the present invention provide
Petition 870190058824, dated 06/25/2019, p. 144/192
8/50 a service consensus method, in order to solve problems in existing technology that stability is relatively weak and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[025] An embodiment of the present invention provides a service consensus method, including the following: obtaining, through a trust protocol node, a pre-processing block, through the use of a first server comprised in the node trust protocol, wherein the trust protocol node includes a plurality of servers and at least one service memory; and perform service consensus in the preprocessing block, through the use of the first server based on each service request stored in the service memory included in the trust protocol node.
[026] Embodiments of the present invention provide a service consensus device, in order to solve problems in existing technology that stability is relatively low and service processing efficiency is relatively weak when a trusted protocol node performs service processing.
[027] An embodiment of the present invention provides a service consensus device, including the following: an acquisition module, configured to obtain a pre-processing block; and a consensus module, configured to perform service consensus in the preprocessing block based on each service request stored in a service memory corresponding to the device.
[028] Embodiments of the present invention provide a method of processing services in order to solve problems in existing technology that the stability is relatively weak and the efficiency of service processing is relatively weak when a protocol node
Petition 870190058824, dated 06/25/2019, p. 145/192
9/50 reliable performs service processing.
[029] An embodiment of the present invention provides a method of processing services, including the following: obtaining, through a registration center, addresses of a plurality of servers comprised in each trust protocol node in a consensus network , in which each trust protocol node includes the plurality of servers and in at least one service memory; and sending the addresses obtained from the plurality of servers comprised in the trust protocol node to other trust protocol nodes in the consensus network and a client for storage.
[030] Embodiments of the present invention provide a service processing device, in order to solve problems in existing technology that the stability is relatively weak and the efficiency of service processing is relatively weak when a trusted protocol node performs service processing.
[031] An embodiment of the present invention provides a service processing device, including the following: an acquisition module, configured to obtain addresses from the plurality of servers comprised in each trust protocol node in a consensus network, in that each trusted protocol node includes the plurality of servers and at least one service memory; and a sending module, configured to send the addresses obtained from the plurality of servers included in the trust protocol node to other trust protocol nodes in the consensus network and a client for storage.
[032] At least one technical solution described above and used in the embodiments of the present invention can achieve the following beneficial effects:
[033] In the embodiments of the present invention, a
Petition 870190058824, dated 06/25/2019, p. 146/192
10/50 first trust protocol node includes a plurality of servers. The first trust protocol node can receive a service request sent by a client and store the service request, using a server comprised in the first trust protocol node, to obtain at least one service request from a memory. service comprised in the first trust protocol node, using the server included in the first trust protocol node, obtain a preprocessing block and send the preprocessing block to each second trust protocol node in a consensus network , through the use of the server to execute service consensus in the pre-processing block, through the use of each second trust protocol node. It can be ensured that the first trust protocol node is available, provided that a server in the plurality of servers comprised in the first trust protocol node is available. Therefore, the stability of the first trust protocol node in the consensus network is greatly improved. In addition, each server included in the first trust protocol node can receive the service request sent by a user, through the use of the client, and each server can initiate service consensus for each second trust protocol node in the network. consensus. Therefore, the service processing efficiency of a trusted protocol service is greatly improved.
Brief Description of the Figures [034] The accompanying drawings described herein are intended to provide a further understanding of the present invention and constitute a part of the present invention. The illustrative embodiments of the present invention and descriptions of the embodiments of the present invention are intended to describe the present invention and are not limitations on the present invention. In the attached drawings:
Petition 870190058824, dated 06/25/2019, p. 147/192
11/50
Figure 1 is a schematic diagram illustrating a service consensus process, in accordance with an embodiment of the present invention;
Figure 2 is a schematic diagram of sending an address to a customer through a registration center, in accordance with an embodiment of the present invention;
Figure 3 is a schematic diagram of sending an address from each server on a second trust protocol node to each server on a first trust protocol node by a registration center, in accordance with an embodiment of the present invention. ;
Figure 4 is a schematic diagram for determining an identifier to be verified by a server, according to an embodiment of the present invention;
Figure 5 is a schematic diagram illustrating a process of achieving service consensus in a pre-processing block by a server on a second trust protocol node, in accordance with an embodiment of the present invention;
Figure 6 is a schematic structural diagram illustrating a service processing device, according to an embodiment of the present invention;
Figure 7 is a schematic structural diagram illustrating a service processing device, according to an embodiment of the present invention;
Figure 8 is a schematic structural diagram illustrating a service processing device, according to an embodiment of the present invention;
Figure 9 is a schematic structural diagram illustrating a service consensus device, according to an embodiment of the
Petition 870190058824, dated 06/25/2019, p. 148/192
The present invention;
Figure 10 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention;
Figure 11 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention; and
Figure 12 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention.
Detailed Description of the Invention [035] To enable a person skilled in the art to better understand the technical solutions in the present invention, the following describes clearly and completely the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in embodiments of the present invention. Clearly, the described embodiments are only a few, but not all, of the embodiments of the present invention. All other embodiments obtained by a person skilled in the art based on the embodiments of the present invention without creative efforts must fall within the scope of protection of the present invention.
[036] Figure 1 is a schematic diagram illustrating a service consensus process, in accordance with an embodiment of the present invention, specifically including the following steps.
[037] (S101) A first trust protocol node receives, through the use of a server on a plurality of servers included in the first trust protocol node, a service request sent by client software.
Petition 870190058824, dated 06/25/2019, p. 149/192
13/50 [038] In this embodiment of the present invention, in a service processing process, a user can send a service request to a first trust protocol node, through the use of a client. The customer mentioned here can be a customer installed on an end user device maintained by the user. The user can start the client on the end user's device and enter service information in an interface displayed by the client to the user. After receiving the service information entered by the user, the customer can generate a corresponding service request based on the service logic pre-stored on the customer and send the service request to the first trust protocol node, using the device end user.
[039] Certainly, in this embodiment of the present invention, the user can directly enter the service information corresponding to the end user's device, and the end user's device can generate a corresponding service request based on the service information entered by the end user. and send the service request to the first trusted protocol node.
[040] In this embodiment of the present invention, the first trust protocol node includes a plurality of servers (in other words, the first trust protocol node includes a server cluster and the server cluster is equivalent to the first node protocol), and servers share node configuration information such as a point-to-point routing table, a node's asymmetric public / private key, and node identity (ID). Therefore, for other trust protocol nodes in a consensus network and on the client, all operations performed by the servers on the first trust protocol node are all considered to be performed by the first trust protocol node.
[041] Therefore, when sending the service request to the first
Petition 870190058824, dated 06/25/2019, p. 150/192
14/50 trust protocol node, the client must first determine a server on the first trust protocol node to which the service request is to be sent. Therefore, this embodiment of the present invention provides a registration center. The registration center is configured to manage server addresses on a trusted protocol node and send the server addresses to the client. The customer can randomly select an address from the addresses sent by the registration center and send the service request to a server corresponding to the address, shown in Figure 2.
[042] Figure 2 is a schematic diagram of sending an address to a customer by a registration center, according to an embodiment of the present invention.
[043] In Figure 2, the first trust protocol node includes the plurality of servers, and each server can register with the registration center when it is online (“online” mentioned here means that the server normally starts the service processing), that is, registration center that the server is currently in an available state and can receive the service request sent by the client. After determining that the server is online, the registration center can obtain an address from the server and then send the address to the customer, so that the customer stores the address after receiving the address.
[044] In this embodiment of the present invention, the registration center can proactively obtain the server address from the server, or the server can provide the address for the registration center. For example, after the server registers with the registration center, the registration center can return a successful registration message to the server. The server can proactively send the server's address to the registration center after receiving the message, so that the registration center
Petition 870190058824, dated 06/25/2019, p. 151/192
15/50 manage the address.
[045] In addition, the registration center can proactively push the obtained address to the customer, the customer can also obtain addresses managed proactively by the registration center. For example, in addition to sending the service request to the first trust protocol node, the customer can also send an address acquisition inquiry message to the registration center. After receiving the inquiry message, the registration center can send an address from a currently available server (that is, a server that is registering at the registration center) to the customer, so that after receiving addresses sent by the registration center registration, the client selects an address from the addresses and sends the service request to a server corresponding to the selected address. Of course, the client can also obtain the addresses of the servers included in the first trust protocol node from the registration center, using other methods. Details are omitted here.
[046] It is worth noting that, in practice, a server on the first trust protocol node is possibly offline (in other words, the server cannot perform service processing) due to a failure in execution, restart of the program etc. If the registration center sends an address from the offline server to the client, and the client selects exactly the address of the offline server during server selection, the client possibly cannot send the service request to the first protocol node trust and the first trust protocol node cannot process the service request.
[047] To avoid problems, in this embodiment of the present invention, the registration center can regularly send a pulse detection message to each server registered in the registration center.
Petition 870190058824, dated 06/25/2019, p. 152/192
16/50 registration. The server can return a response message to the registration center based on the heartbeat detection message it receives when it is running normally online. After receiving the response message, the registration center can determine that the server is running normally online and continues to manage a server address.
[048] After sending the heartbeat detection message to the server, if it detects that no response message returned by the server based on the heartbeat detection message is received after a specified time has elapsed, the registration center may determine that the server is possibly currently offline due to a failed execution, a program restart, etc., and does not send the server address to the client. In addition, if the registration center has sent the server address to the customer, the registration center can send a notification that the server is offline to the customer, so that the customer locally deletes the server address with basis of the notification.
[049] After deleting the address of the offline server, the client does not send the service request to the server. When the server is back online, the client retrieves the server address from the registration center and sends the service request to the server, using the address.
[050] It is worth noting that Figure 2 is merely described, using an example that the client obtains the addresses included in the first trust protocol node of the registration center. In Figure 2, since the first trust protocol node can receive the service request sent by the customer's client, the servers on the first trust protocol node need to register with the registration center, so that the registration center can send server addresses the first trusted protocol node for the client, and the client can send the
Petition 870190058824, dated 06/25/2019, p. 153/192
17/50 service request for servers on the first trust protocol node, using the addresses obtained.
[051] However, in practice, the second trust protocol nodes in the consensus network can also receive the service request sent by the customer and process the service request. Therefore, in this embodiment of the present invention, the servers included in each second trust protocol node in the consensus network can also register with the registration center, so that the registration center can send addresses to the customers included in the second trust protocol node. As such, the client can also send the service request to the servers in the second trust protocol node, using the addresses obtained.
[052] (S102) Store, using the server, the service request in a service memory comprised in the first trust protocol node and send the service request to each second trust protocol node in a consensus network , so that each second trust protocol node stores the service request in a service memory comprised in the second trust protocol node after receiving the service request.
[053] After receiving the service request sent by the client, the server included in the first trust protocol node can store the service request in the service memory included in the first trust protocol node. In addition, the server can send the service request sent by the client to each second trust protocol node in the consensus network, so that the second trust protocol node stores the service request in the service memory comprised in the second node of trust protocol after receiving the service request.
Petition 870190058824, dated 06/25/2019, p. 154/192
18/50 [054] The server on the first trust protocol node can first perform a valid check on the service request after receiving the service request. The valid verification can be a valid verification, using an asymmetric signature, such as an RSA algorithm, or it can be verified in other forms. When determining that the service request is successful in valid verification, the server can store the service request in the service memory comprised in the first trust protocol node and send the service request to each second trust protocol node in the consensus network. When determining that the service request was not successful in valid verification, the server does not store the service request, but may return a message indicating that the service request was not processed on the client, so that the user performs certain operations after reading the message, through the use of the client. For example, the user can reissue the service request on the client and send an edited service request to the server comprised in the first trust protocol node, using the client after reading the message.
[055] In this embodiment of the present invention, each trust protocol node in the consensus network can include a plurality of servers. Therefore, when sending the service request to the second trust protocol node, the server on the first trust protocol node also needs to obtain addresses from the servers on the second trust protocol node, and then sends the service request to servers included in the second trust protocol node, using the obtained addresses.
[056] Therefore, in this embodiment of the present invention, the registration center also needs to manage the addresses of the servers in the second trust protocol node, and sends the addresses of the servers in the
Petition 870190058824, dated 06/25/2019, p. 155/192
19/50 second trust protocol node for each server in the first trust protocol node, which is shown in Figure 3.
[057] Figure 3 is a schematic diagram of sending an address from each server on a second trust protocol node to each server on a first trust protocol node by a registry center, according to an embodiment of the present invention.
[058] In Figure 3, servers in the second trust protocol node can also register with the registration center after being online, so that the registration center obtains the addresses of the servers in the second trust protocol node. . The registration center can proactively obtain the addresses of the servers in the second trust protocol node, or the servers in the second trust protocol node can proactively send their addresses to the registration center. A specific method is the same as the method described earlier in step (S101) of obtaining the addresses of the servers in the first trust protocol node by the registration center, and details are omitted here.
[059] After obtaining the addresses of the servers in the second trust protocol node, using the registration center, each server in the first trust protocol node can store the obtained addresses. When sending the service request to the second trust protocol node, the server at the first trust protocol node can select an address from the stored addresses included in the second trust protocol node and then send the service request to a server corresponding to the address, so that the server corresponding to the address stores the service request in the service memory corresponding to the second trust protocol node after receiving the service request.
[060] The server on the second trust protocol node
Petition 870190058824, dated 06/25/2019, p. 156/192
20/50 can also perform a valid check on the service request after receiving the service request. The server can store the service request in the service memory comprised in the second trust protocol node when determining whether the service request is successful in valid verification. The server does not store the service request when determining that the service request is unsuccessful in valid verification.
[061] It is worth noting that the servers included in the second trust protocol node are also possibly offline, as mentioned in step (S101). Therefore, after obtaining the addresses of the servers on the second trust protocol node, the registry center can regularly send a heartbeat detection message to the servers corresponding to those addresses. Upon receiving a response message returned by a server based on the heartbeat detection message after a specified time has elapsed (or within a specified time), the registration center can determine that the server is still in an online state and continues to manage an address from the server. When not receiving the response message returned by the server based on the heartbeat detection message after the specified time has elapsed, the registration center will be able to determine if the server is possibly offline due to a running failure, network instability, etc. . and will not continue to manage the server address until the server is back online.
[062] In addition, by determining, using the method described above, that a particular server on the second trust protocol node is offline, the registry center can send a notification that the server is offline to the servers in the first trust protocol node and the client, so that the servers in the first trust protocol node and the client exclude an address from the server after
Petition 870190058824, dated 06/25/2019, p. 157/192
21/50 receive the notification and subsequently do not send the service request to the server corresponding to the address until the server is online again. After retrieving the server address from the registration center, the servers in the first trust protocol node and the client can send the service request to the server corresponding to the address, using the obtained address.
[063] Figure 3 shows just one case where servers are comprised of a second trust protocol node record with a record center. In practice, there are a plurality of second trusted protocol nodes in a consensus network. Therefore, the servers at each second trust protocol node in the consensus network can register with the registration center after going online, so that the registration center obtains addresses from the servers in the second trust protocol node and sends the addresses obtained for the servers in the first trust protocol node. In other words, each server in the first trust protocol node stores the addresses of the servers comprised in each second trust protocol node in the consensus network.
[064] It is worth noting that, in practice, the entire consensus network includes a plurality of trust protocol nodes. The first trust protocol node mentioned in this embodiment of the present invention is a trust protocol node that receives the service request sent by the client, and other trust protocol nodes that the first trust protocol node can be called seconds of reliable protocol nodes in this embodiment of the present invention. The first trust protocol node and the second trust protocol node are relative terms. To be specific, a trust protocol node that receives the service request from the client can be referred to as the first trust protocol node, and a trust protocol node that
Petition 870190058824, dated 06/25/2019, p. 158/192
22/50 receives the service request sent by the first trust protocol node can be referred to as the second trust protocol node. Since trust nodes in the consensus network can receive the service request sent by the client, trust nodes can be essentially the first trust nodes or they can be the second trust nodes. The division between the first trust protocol node and the second trust protocol node depends on where the service request is received.
[065] Certainly, in a consensus verification process, the division between the first trust protocol node and the second trust protocol node can also be determined based on which node initiates the consensus verification. To be specific, a consensus verification initiator that sends a preprocessing block that includes at least one service request to the consensus network can be the first trust protocol node and a trust protocol node that receives the block Preprocessing can be referred to as the second trust protocol node.
[066] (S103) Select a server from the plurality of servers included in the first trust protocol node and obtain at least one service request from a service memory included in the first trust protocol node, using the server selected, in a service consensus phase.
[067] In this embodiment of the present invention, the server on the first trust protocol node needs to execute service consensus on the service request in the service memory comprised on the first trust protocol node. Therefore, in the service consensus phase, the server in the first trust protocol node can obtain at least one service request from the service memory comprised in the first
Petition 870190058824, dated 06/25/2019, p. 159/192
23/50 trust protocol node and then package the service request obtained in a preprocessing block and send the preprocessing block to each second trust protocol node in the consensus network for service consensus.
[068] In this embodiment of the present invention, in addition to the plurality of servers and service memory, the first trust protocol node also includes a scheduled task trigger, and the scheduled task trigger is used to periodically initiate consensus of service for each trust protocol node in the consensus network, using the server on the first trust protocol node. However, since the first trust protocol node includes the plurality of servers, the scheduled task trigger can select a server from the plurality of servers comprised in the first trust protocol node in the service consensus phase and then , the server obtains at least one service request from the service memory comprised in the first trust protocol node.
[069] In this embodiment of the present invention, the scheduled task trigger may be a hardware device, or it may be a form of software. For a form of software, the scheduled task trigger can be defined on a given server in the first trust protocol node. When executed on the server, the scheduled task trigger can select a server from the servers comprised in the first trust protocol node in the service consensus phase and send a notification to the selected server, using a server on which the task trigger is located, so that the selected server obtains at least one request from the service memory comprised in the first trust protocol node after receiving the notification.
Petition 870190058824, dated 06/25/2019, p. 160/192
24/50 [070] In the process of obtaining each service request from the service memory (that is, the service memory comprised in the first trust protocol node), the server can obtain each service request based on the sequence of time that each service request stores in service memory, or get each service request based on the type of service for each service request, or can get each service request based on the service level of each service request. There are many methods of acquisition and details are omitted here.
[071] (S104): Package at least one service request in a pre-processing block, using the selected server and send the pre-processing block to each second trust protocol node in the consensus network, through the use of the selected server, so that each second trust protocol node realizes service consensus in the pre-processing block.
[072] After obtaining at least one service request from the service memory comprised in the first trust protocol node, the server in the first trust protocol node can process the service requests obtained and package the service requests in a pre-processing block. The server can order service requests obtained based on a predetermined classification rule to obtain a classification result of service requests and determine, using a predetermined identifier determination rule and the classification result , an identifier to be verified that corresponds exclusively to the requests service. The server can then package the service requests obtained, the result of the classification of the service requests and the identifier determined to be verified in a preprocessing block and then send the preprocessing block to the servers comprised in the second protocol node
Petition 870190058824, dated 06/25/2019, p. 161/192
25/50 confidence.
[073] A specific method for determining the identifier to be verified by the server can be shown in Figure 4.
[074] Figure 4 is a schematic diagram for determining an identifier to be verified by a server, according to an embodiment of the present invention.
[075] In Figure 4, a server on the first trust protocol node (that is, a determined server, using the scheduled task trigger comprised on the first trust protocol node) obtains four service requests shown in Figure 4 from the service memory included in the first trust protocol node. The server can classify the four service requests based on a predetermined classification rule, in order to obtain a classification result shown in Figure 4. The server can then separately determine the child identifiers Hashl to Hash4 corresponding to the four service requests based on a predetermined identifier determination rule: a hash algorithm, and place the four determined child identifiers on leaf nodes of a Merkle tree from left to right based on a classification result obtained, to determine a value Hash7 at the root node of the Merkle tree. The server can determine the determined Hash7 value on the root node of the Merkle tree as an identifier to be verified that corresponds exclusively to the four service requests and then packages the determined identifier to be verified, the classification result and the four services requests in a preprocessing block.
[076] It is worth noting that the method of determining the identifier to be verified shown in Figure 4 is not unique. For example, in addition to determining the identifier to be verified that corresponds
Petition 870190058824, dated 06/25/2019, p. 162/192
26/50 exclusively to service requests, using the hash algorithm as the determinant rule of the predetermined identifier, the server in the first trust protocol node can further determine the identifier to be verified that corresponds exclusively to the service requested , using an algorithm such as a message digest algorithm (5) (MD5), provided that the identifier determined to be verified corresponds only to service requests. In addition to the shape shown in Figure 4, the Merkle tree can also have other shapes. Details are omitted here.
[077] Certainly, in this embodiment of the present invention, in addition to the Merkle tree, the server in the first trust protocol node can further determine the identifier to be verified that corresponds exclusively to service requests, through the use of other methods . For example, after determining the child identifiers corresponding to the service requests, the server can classify the determined child identifiers based on a given sequence, encrypt the classified result again, and use the encrypted result as the identifier to be verified that corresponds exclusively to the service. of requests. Alternatively, after determining the child identifiers corresponding to the service requests, the server can generate a universally unique ID, using a snowflake algorithm and use the ID as the identifier to be verified that corresponds exclusively to the requests for service. service. Alternatively, the server can determine a universally unique identifier (UUID) from the given child identifiers corresponding to the service requests and use the UUID as the identifier to be verified that corresponds exclusively to the service requests. Certainly, there are still other methods of determination, and details are omitted here, as long as it is ensured that the identifier
Petition 870190058824, dated 06/25/2019, p. 163/192
27/50 determined to be verified may correspond exclusively to service requests.
[078] After determining the preprocessing block, the server on the first trust protocol node (that is, the selected server, using the scheduled task trigger on the first trust protocol node in the consensus phase of service) can send the preprocessing block to each second trust protocol node in the consensus network. However, each second trust protocol node in the consensus network includes a plurality of servers. Therefore, when sending the preprocessing block, the server at the first trust protocol node must determine a server at each second trust protocol node to which the preprocessing block is sent.
[079] In this embodiment of the present invention, each server in the first trust protocol node can obtain the addresses of the servers comprised in each second trust protocol node in the consensus network from the registration center. Therefore, when the server on the first trust protocol node needs to send the preprocessing block to a given second trust protocol node on the consensus network, the server can select an address from the stored addresses of the servers on the second trust protocol node (the stored addresses are addresses of servers in the second trust protocol node that are in an online state) and send the pre-processing block to a server corresponding to the address, so that the server corresponding to the address performs a check consensus in the preprocessing block after receiving the preprocessing block.
[080] There are a plurality of second trust protocol nodes in the consensus network. Therefore, when sending the prepack
Petition 870190058824, dated 06/25/2019, p. 164/192
28/50 processing for each second trust protocol node, the server on the first trust protocol node can separately determine, from the stored addresses, using the method described above, servers on each second trust protocol node that receive the preprocessing block and separately send the preprocessing block to the servers on each second trust protocol node, using the given addresses.
[081] For the second trust protocol node, after receiving the preprocessing block sent by the server on the first trust protocol node, the server comprised on the second trust protocol node can analyze the preprocessing block , to determine service requests included in the pre-processing block, a result of the classification of service requests and an identifier to be verified. Then, the server on the second trust protocol node can find service requests that match the service requests comprised in the service memory preprocessing block comprised on the second trust protocol node and determine, using a predetermined identifier determination rule and the classification result determined the service requests, an identifier that corresponds exclusively to the service requests found in the service memory comprised in the second trust protocol node. The predetermined identifier determination rule mentioned here is the same as the identifier determination rule used by the server on the first trust protocol node.
[082] The server on the second trust protocol node can compare the given identifier with the identifier to be verified that is comprised in the preprocessing block after determining the identifier and can determine that the preprocessing block is well
Petition 870190058824, dated 06/25/2019, p. 165/192
29/50 succeeded in checking local consensus (in other words, which is performed by the server on the second trust protocol node) by determining that the two are consistent and then storing a verification result in the service memory comprised in the second trust protocol node and send the verification result to other trust protocol nodes in the consensus network (the other trust protocol nodes mentioned here include each second trust protocol node and the first trust protocol node) .
[083] The method of sending the verification result by the server on the second trust protocol node is the same as the method of sending the service request or the preprocessing block for each second trust protocol node on the network. consensus by the server on the first trust protocol node. To be specific, when the server at the second trust protocol node needs to send the verification result to a given trust protocol node in the consensus network (which can be the second trust protocol node, or it can be the first node protocol), the server can select an address from the addresses stored locally from the servers on the trust protocol node and send the verification result to a server corresponding to the address. After receiving the verification result, the server corresponding to the address can store the verification result in a service memory comprised in the trust protocol node to which the server belongs.
[084] When the server in the second trust protocol node sends the verification result to each trust protocol node in the consensus network, other servers in the second trust protocol node or the server may also receive verification results about the pre-processing block that are sent by other nodes of
Petition 870190058824, dated 06/25/2019, p. 166/192
30/50 trust protocol in the consensus network and store all received verification results in the service memory included in the second trust protocol node. Then, the server (the server can be a server that receives the preprocessing block) on the second trust protocol node can determine, from the service memory comprised on the second trust protocol node, a verification result ( including a verification result obtained by the server) on the preprocessing block that is obtained by each trust protocol node in the consensus network and determines a comprehensive verification result on the preprocessing block that is obtained by each protocol node of trust in the consensus network. The server can then send the given comprehensive scan result to each trust protocol node in the consensus network, using a method that is the same as sending the scan result and storing the comprehensive scan result in memory of service comprised in the second trust protocol node.
[085] After the server on the second trust protocol node sends the comprehensive verification result, other servers on the second trust protocol node or on the server (that is, a server that sends the comprehensive verification result) may also receive a comprehensive verification result on the preprocessing block sent by each trust protocol node (including each second trust protocol node and the first trust protocol node) in the consensus network and stores the comprehensive verification in the memory of service comprised in the second trust protocol node.
[086] The server (that is, the server that sends the comprehensive verification result) on the second trust protocol node can obtain a comprehensive verification result sent by other trust protocol nodes in the consensus service memory network at the
Petition 870190058824, dated 06/25/2019, p. 167/192
31/50 second trust protocol node, determine, through the use of received a comprehensive verification result and a comprehensive verification result determined by the server, whether the preprocessing block succeeds in service consensus on the consensus network and writes each service request comprised in the preprocessing block to a trust protocol in which the second trust protocol node is stored, if it is determined that each service request comprised in the preprocessing block is successful in the service consensus in the consensus network based on the comprehensive verification results (including the comprehensive verification result determined by the server) stored in the service memory or do not write each service request in the trust protocol. The server on the second trust protocol node can write the complete content of each service request in the trust protocol, or it can write only a summary of information for each service request in the trust protocol.
[087] The service consensus process described above is relatively complex. To facilitate understanding, the following lists a simple example to clearly describe the process of achieving service consensus in the preprocessing block by the server on the second trust protocol node, which is shown in Figure 5.
[088] Figure 5 is a schematic diagram illustrating a process of realizing service consensus in a preprocessing block by a server in a second trust protocol node, according to an embodiment of the present invention.
[089] Suppose there are three trust protocol nodes in a consensus network: a first trust protocol node, a second trust protocol node A and a second trust protocol node B. Each server on the three trust nodes trust protocol respectively
Petition 870190058824, dated 06/25/2019, p. 168/192
32/50 stores server addresses included in the other two trust protocol nodes. A server # 3 on the first trust protocol node obtains at least one service request from a service memory comprised on the first trust protocol node, packages at least one service request in a preprocessing block and sends the preprocessing block for the other two trust protocol nodes. Server # 3 determines to send the preprocessing block separately to a server A1 and a server B1 using server addresses comprised in the other two trust protocol nodes that are stored on server # 3.
[090] After receiving the preprocessing block, server A1 and server B1 can perform consensus verification in the preprocessing block and respectively store the verification results obtained for the preprocessing block in the service memories comprised of the trust protocol nodes to which server A1 and server B1 belong. In addition, server A1 and server B1 can respectively send the determined verification results to the other two trust protocol nodes in the consensus network. Server A1 determines to send a verification result obtained by server A1 to a server # 2 on the first trust protocol node and a server B2 on the second trust protocol node B based on the addresses of the servers on the other two protocol nodes that are stored on server A1, and server B1 determines to send a verification result obtained by server B1 to server # 3 on the first trust protocol node and a server A3 on the second trust protocol node A.
[091] After receiving the verification results sent by the servers on the other two protocol protocol nodes separately
Petition 870190058824, dated 06/25/2019, p. 169/192
33/50 trust, the servers in the three trust protocol nodes in the consensus network can store the verification results received in the service memories included in the trust protocol nodes. Server A1 (that is, a server that receives the pre-processing block) can obtain verification results (including a verification result obtained by server A1) from a service memory comprised in the second trust protocol node A and obtain a result of comprehensive verification of the trust protocol node in the consensus network for the preprocessing block based on these verification results. Server A1 can store the comprehensive scan result obtained in the service memory comprised in the second trust protocol node A and send the comprehensive scan result to the other two trust protocol nodes. The shipping method is the same as the shipping method for sending the verification result and details are omitted here. Server # 3 (that is, a server that sends a service consensus) and server B1 (a server that receives the pre-processing block) can also determine a comprehensive verification result for the pre-processing block using this method and sending the comprehensive verification obtained will result in the other two trust protocol nodes in the consensus network.
[092] After receiving the verification results sent by the other two trust protocol nodes, the servers in the trust protocol nodes in the consensus network can store the verification results received in the service memories included in the trust protocol nodes .
[093] Server A1 can obtain comprehensive verification results (including a comprehensive verification result obtained by server A1) for the preprocessing block, which are sent by the trust protocol nodes, from the service memory comprised in the second
Petition 870190058824, dated 06/25/2019, p. 170/192
34/50 trust protocol node A. The Α1 server can then determine whether the preprocessing block is successful in service consensus on the consensus network based on comprehensive verification results. If yes, server A1 writes each service request comprised in the preprocessing block in a trust protocol of the second trust protocol node A, and if not, server A1 does not write each service request in the trust protocol. Likewise, server # 3 and server B1 can also obtain, using such method, comprehensive results of verifying the service memories comprised in the trust protocol nodes to which server # 3 and server B1 belong and determine, with based on the obtained comprehensive verification results, either to record each service request included in the pre-processing block on the trust protocol nodes of server # 3 and on server B1.
[094] It can be learned from the method described earlier that each trust protocol node in the consensus network includes a plurality of servers. Therefore, as long as one of the servers in each trust protocol node is in an online state, in other words, it is available, the trust protocol node is a trust protocol node available in the consensus network, which greatly improves the stability of the trust protocol node in the consensus network. In addition, each trust protocol node includes a plurality of servers, and the roles and status of the servers are the same for the trust protocol node. In other words, compared to existing technology, equivalent servers are added to the trusted protocol node. This greatly improves the performance of the trust protocol node and, therefore, the efficiency of service processing of the trust protocol node is greatly improved.
[095] It is worth noting that in a consensus process of
Petition 870190058824, dated 06/25/2019, p. 171/192
35/50 service, each trust protocol node in the consensus network can determine a verification result obtained by the trust protocol node for the preprocessing block, send the verification result to other trust protocol nodes in the network consensus and store the verification result in a service memory corresponding to the trust protocol node. The trust node can perform a consensus check in the preprocessing block, using a first server comprised in the trust protocol node, and the first server can be a server specified in the trust protocol node or it can be a server selected from servers included in the trust protocol node.
[096] In addition, the trust protocol node also receives a verification result sent by other trust protocol nodes in the consensus network to the preprocessing block. The trust protocol node can receive, through the use of a server included in the trust protocol node, the verification result sent by the other trust protocol nodes and stores the verification result received in the service memory corresponding to the trust node. trust protocol. Here, a server that receives the verification result sent by the other trusted protocol nodes can be referred to as a second server. The second server can be any server on the trusted protocol node, and it can certainly be the first server described earlier. Which second server to receive the verification result sent by the other trust protocol nodes depends on the second server selected, by a server included in the other trust protocol nodes, to receive the verification result sent by the other trust protocols.
[097] In step (S101), in addition to randomly selecting one
Petition 870190058824, dated 06/25/2019, p. 172/192
36/50 address of addresses stored on servers in the first trust protocol node, the client can also select an address based on a load-balanced status. Therefore, by sending the addresses of the servers on the first trust protocol node to the client, the registration center can jointly send the load status of the servers to the client, so that the client selects an address from a lightly loaded server from the addresses, using a predetermined load balancing algorithm and sends the service request to the server corresponding to the address.
[098] Likewise, when sending the service request to each second trust protocol node in the consensus network, the server in the first trust protocol node can also select a server from the addresses stored based on the method of balancing the charge. Of course, the server at the first trust protocol node can also send the preprocessing block based on the load balancing method, and each trust protocol node in the consensus network can also send the verification result and the result comprehensive verification based on the load balancing method. A specific process is the same as the method of sending the service request to the first trust protocol node by the customer based on the load balancing method, and details are omitted here.
[099] In this embodiment of the present invention, in addition to selecting a server that initiates service consensus, using the scheduled task trigger, the consensus periods can be defined respectively on the servers in the trust protocol node (including the first trust protocol node and the second trust protocol node) and different servers have different periods of consensus. Upon detecting that a current time reaches a server consensus period, the
Petition 870190058824, dated 06/25/2019, p. 173/192
The server can obtain at least one service request from a service memory on the trusted protocol node to which the server belongs.
[0100] In this embodiment of the present invention, the server on the trust protocol node (including the first trust protocol node and the second trust protocol node) can also forward the service request to other servers on the trust node trust protocol after receiving the service request, and the other servers store the service request in a service memory comprised in the trust protocol node. After receiving the preprocessing block sent by the first trust protocol node, the server at each second trust protocol node in the consensus network can also forward the preprocessing block to other servers in the second trust protocol node. confidence to check consensus and store the result obtained in the memory service included in the second trust protocol node.
[0101] The service consensus method according to the embodiments of the present invention is described above. Based on the same idea, an embodiment of the present invention further provides the following service processing devices and service consensus devices, which are shown in Figure 6 to Figure 12.
[0102] Figure 6 is a schematic structural diagram illustrating a service processing device, in accordance with an embodiment of the present invention, specifically including the following: a receiving module (601), configured to receive a service request sent by a customer; a storage module (602), configured to store the service request in a service memory corresponding to the device; and a sending module (603), configured to send the service request to each second node
Petition 870190058824, dated 06/25/2019, p. 174/192
38/50 trust protocol in a consensus network, so that each second trust protocol node stores the service request in a service memory comprised in the second trust protocol node after receiving the service request. The second trust protocol node includes a plurality of servers and at least one service memory.
[0103] The device also includes the following: a registration module (604), configured to send a device address to a registration center when it is determined that the device is online, so that the registration center sends the address for the client and every second trust protocol node in the consensus network.
[0104] The device also includes the following: an acquisition module (605), configured to obtain addresses from the plurality of servers included in each second protocol trust node of a registration center.
[0105] The sending module (603) is specifically configured to select an address from the addresses obtained from the plurality of servers included in each second trust protocol node; and send the service request to a server corresponding to the selected address.
[0106] The storage module (602) is specifically configured to perform valid verification on the service request; and store the service request in service memory when it is determined that the service request is successful in valid verification.
[0107] The storage module (602) is further configured to ignore the service request storage when it is determined that the service request was not successful in valid verification.
[0108] A trust protocol node includes a plurality of
Petition 870190058824, dated 06/25/2019, p. 175/192
39/50 devices.
[0109] Figure 7 is a schematic structural diagram illustrating a service processing device, in accordance with an embodiment of the present invention, specifically including the following: a request receiving module (701), configured for receiving a service request sent by a first trust protocol node, wherein the first trust protocol node includes a plurality of servers and at least one service memory; and a request storage module (702), configured to store the service request in a service memory corresponding to the device.
[0110] The device also includes the following: a registration module (703), configured to send a device address to a registration center when it is determined that the device is online, so that the registration center sends the address for the first trust protocol node, a client, and other nodes of the second trust protocol node in a consensus network.
[0111] The request storage module (702) is specifically configured to perform a valid check on the service request; and store the service request in service memory when it is determined that the service request is successful in valid verification.
[0112] The request storage module (702) is further configured to ignore service request storage when it is determined that the service request was not successful in valid verification.
[0113] Figure 8 is a structural schematic diagram illustrating a service processing device, in accordance with an embodiment of the present invention, specifically including the following:
Petition 870190058824, dated 06/25/2019, p. 176/192
40/50 an information receiving module (801), configured to receive service information entered by a user; a request generation module (802), configured to generate a corresponding service request based on the service information; and a sending module (803), configured to send the service request to a server comprised in a first trust protocol node, so that the first trust protocol node stores the service request received in a service memory comprised in the first trust protocol node; and sending the service request to each second trust protocol node in a consensus network, where the first trust protocol node includes a plurality of servers and at least one service memory, and the second trust protocol node includes a plurality of servers and at least one service memory.
[0114] The sending module (803) is specifically configured to obtain addresses from the plurality of servers included in the first trust protocol node from a registration center; and selecting an address from the addresses obtained from the plurality of servers included in the first trust protocol node, and sending the service request to a server corresponding to the selected address.
[0115] The device also includes the following: an exclusion module (804), configured to eliminate an address from a specific server when an offline notification is received by the server's registration center.
[0116] Figure 9 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention, specifically including the following: a request acquisition module (901), configured for obtain at least one service request from a service memory corresponding to the
Petition 870190058824, dated 06/25/2019, p. 177/192
41/50 device; and a sending module (902), configured to package at least one service request in a preprocessing block, and sending the preprocessing block to each second trust protocol node in a consensus network, so that each second trust protocol node performs service consensus in the preprocessing block, the second trust protocol node includes a plurality of servers and at least one service memory.
[0117] The device also includes the following: an address acquisition module (903), configured to obtain addresses from the plurality of servers included in each second trust protocol node from a registration center.
[0118] The sending module (902) is specifically configured to select an address from the addresses obtained from the plurality of servers included in each second trust protocol node; and sending the preprocessing block to a server corresponding to the selected address, so that the server corresponding to the selected address performs service consensus on the received preprocessing block.
[0119] Figure 10 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention, specifically including the following: a selection module (1001), configured to select a server from a plurality of servers comprised in a first trust protocol node, wherein the first trust protocol node includes the plurality of servers and at least one service memory.
[0120] The selection module (1001) is specifically configured to detect whether a current moment satisfies a task trigger condition; and select the server from the plurality of servers
Petition 870190058824, dated 06/25/2019, p. 178/192
42/50 comprised in the first trust protocol node when detecting that the task trigger condition is satisfied.
[0121] Figure 11 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention, specifically including the following: an acquisition module (1101), configured to obtain a preprocessing block; and a consensus module (1102), configured to perform service consensus in the preprocessing block based on each service request stored in a service memory corresponding to the device.
[0122] The consensus module (1102) is specifically configured to carry out consensus verification in the preprocessing block, in order to obtain a verification result; receiving each verification result sent by other trusted protocol nodes in a consensus network and storing each verification result received in the service memory corresponding to the device; and obtain each service memory verification result and perform service consensus in the pre-processing block, using each obtained verification result.
[0123] Figure 12 is a schematic structural diagram illustrating a service consensus device, in accordance with an embodiment of the present invention, specifically including the following: an acquisition module (1201), configured to obtain addresses the plurality of servers comprised in each trust protocol node in a consensus network, where each trust protocol node includes the plurality of servers and at least one service memory; and a sending module (1202), configured to send addresses obtained from the plurality of servers included in the trust protocol node to other trust protocol nodes in the consensus network and a client to
Petition 870190058824, dated 06/25/2019, p. 179/192
43/50 storage.
[0124] The device also includes the following: a notification module (1203), configured to send a pulse detection message to the plurality of servers included in each trust protocol node in the consensus network based on the addresses obtained from the plurality of servers included in the trust protocol node; and when no response message returned by each server comprised in the trust protocol node based on the heartbeat detection message is received after a specified time has elapsed, determine whether the server is offline and instruct the client and the other trust protocol in the consensus network to exclude the stored address from the server.
[0125] Embodiments of the present invention provide a processing and a consensus method and device. In the method, a first trust protocol node includes a plurality of servers. The first trust protocol node can receive a service request sent by a client and store the service request, using the plurality of included servers, obtain at least one service request from a service memory comprised in the first service node. trust protocol, through the use of a server in the plurality of servers, in order to obtain a preprocessing block, and send the preprocessing block to each second trust protocol node in a consensus network, using the server, in order to execute the service consensus in the pre-processing block, through the use of each second trust protocol node. It can be ensured that the first trust protocol node is available, provided that a server in the plurality of servers comprised in the first trust protocol node is available. Therefore, the stability of the first trust protocol node in the
Petition 870190058824, dated 06/25/2019, p. 180/192
44/50 consensus network is improved. In addition, each server included in the first trust protocol node can receive the service request sent by a user, through the use of the client, and each server can initiate service consensus for each second trust protocol node in the network. consensus. Therefore, the service processing efficiency of a trusted protocol service is greatly improved.
[0126] In the 1990s, the improvement of a technology can be clearly distinguished between hardware improvement (for example, improvement in a circuit structure such as a diode, a transistor or a switch) and software improvement (improvement in a procedure method). However, with the development of technologies, the improvement of many method procedures can be considered as a direct improvement of a hardware circuit structure. Designers almost all program an improved method procedure for a hardware circuit in order to obtain a corresponding hardware circuit structure. Therefore, it cannot be said that the improvement of a method procedure cannot be implemented, through the use of a hardware entity module. For example, a programmable logic device (PLD) (for example, an FPGA (Field Programmable Gate Array)) is an integrated circuit. A logic function of the programmable logic device is determined by the component programming performed by a user. Designers carry out voluntary programming to "integrate" a digital system into a single PLD, without requiring a chip manufacturer to design and produce a dedicated integrated circuit chip. In addition, instead of manually producing an integrated circuit chip, programming is mainly implemented by the “logic compiler” software, which is similar to a software compiler used during program development. The original code before compilation is also written in a specific programming language, which is called
Petition 870190058824, dated 06/25/2019, p. 181/192
45/50 hardware description language (HDL), and there are more than one type of HDL, such as ABEL (advanced Boolean expression language), AHDL (Altera hardware description language), Confluence, CUPL (University programming language Cornell), HDCal, JHDL (Java hardware description language), Lava, Lola, MyHDL, PALASM and RHDL (Ruby Hardware Description Language), etc. Currently, VHDL (High Speed Integrated Circuit Hardware Description Language) and Verilog are most commonly used. A person skilled in the art should also understand that a method procedure only needs to be logically programmed and programmed for the integrated circuit, using the previous hardware description languages, so that a hardware circuit that implements the logical method procedure can be easily obtained.
[0127] A controller can be implemented using any appropriate method. For example, the controller can be a microprocessor or processor, or a computer-readable medium, a logic port, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, or an embedded microprocessor that stores program code computer readable (such as software or firmware) that can be run by the microprocessor or processor. Controller examples include, but are not limited to, the following microprocessors: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320. The memory controller can also be implemented as part of the memory control logic. A person skilled in the art also knows that a controller can be implemented using pure computer-readable program code, and steps in the method can be logically scheduled to allow the controller to further implement the same functions in the forms of a logical port, a switch. , an application-specific integrated circuit, a programmable logic controller,
Petition 870190058824, dated 06/25/2019, p. 182/192
46/50 a built-in microcontroller, etc. Therefore, the controller can be considered as a hardware component, and a device that is comprised in the controller and that is configured to implement various functions can also be considered as a structure in the hardware component. Alternatively, a device configured to implement various functions can be considered as a software module to implement the method and a structure in the hardware component.
[0128] The system, device, module or unit described in the described embodiments can be implemented by a computer chip or an entity, or implemented by a product with a certain function. A typical embodiment device is a computer. The computer can be, for example, a personal computer, a portable computer, a cell phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an e-mail device, a game console, a tablet computer, or a wearable device, or a combination of any of those devices.
[0129] To facilitate description, the device described is described by dividing functions into several units. Certainly, when the present invention is implemented, the functions of the units can be implemented in one or more pieces of software and / or hardware.
[0130] A person skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system or a computer program product. Accordingly, the present invention can use a hardware-only embodiment, software-only embodiments or embodiments with a combination of software and hardware. In addition, the present invention can use a form of computer program product that is
Petition 870190058824, dated 06/25/2019, p. 183/192
47/50 implemented on one or more storage media usable per computer (including, but not limited to a disk memory, a CDROM and an optical memory) that include computer usable program code.
[0131] The present description is described with reference to the flowcharts and / or block diagrams of the method, the device (system) and the computer program product according to the embodiments of the present invention. It should be understood that computer program instructions can be used to implement each process and / or each block in flowcharts and / or block diagrams and a combination of a process and / or a block in flowcharts and / or diagrams of blocks. These computer program instructions can be provided for a general purpose computer, a dedicated computer, an embedded processor, or a processor of any other programmable data processing device to generate a machine so that instructions executed by a computer or processor from any other A programmable data processing device generates a device to implement a specific function in one or more processes in flowcharts or in one or more blocks in block diagrams.
[0132] These computer program instructions can be stored in a computer-readable memory that can instruct the computer or any other programmable data processing device to work on a specific method, so that the instructions stored in the computer generated memory generate an artifact that includes an instructional device. The instruction device implements a specific function in one or more processes in the flowcharts and / or in one or more blocks in the block diagrams.
[0133] These computer program instructions can be
Petition 870190058824, dated 06/25/2019, p. 184/192
48/50 loaded to a computer or other programmable data processing devices, so that a series of operations and steps are performed on the computer or on the other programmable devices, generating computer-implemented processing. Therefore, instructions executed on the computer or other programmable devices provide steps to implement a specific function in one or more processes in flowcharts or in one or more blocks in block diagrams.
[0134] In a typical configuration, the computing device includes one or more processors (CPU), one or more input / output interfaces, one or more network interfaces and one or more memories.
[0135] The memory may include non-persistent memory, random access memory (RAM) and / or non-volatile memory in a computer-readable medium, for example, read-only memory (ROM) or flash memory (memory Flash RAM).
[0136] The computer-readable medium includes persistent, non-persistent, mobile and immobile media that can implement information storage using any method or technology. The information can be a computer-readable instruction, a data structure, a program module or other data. A computer storage medium includes, but is not limited to, parameter random access memory (PRAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a random access memory ( RAM) of other types, a read-only memory (ROM), an electrically erasable programmable and read-only memory (EEPROM), a flash memory or other memory technologies, a compact disk read memory (CD-ROM), a versatile digital disc (DVD) or other optical storage devices, a magnetic tape, magnetic disk storage, other magnetic storage devices or any other
Petition 870190058824, dated 06/25/2019, p. 185/192
49/50 non-transmission means that can be used to store information that can be accessed by the computing device. Based on the definition of this specification, the computer-readable medium does not include a computer-readable transient medium (transient medium), for example, a modulated and carrier data signal.
[0137] It is also worth noting that the term “include”, “contain” or any other variant is intended to cover a non-exclusive inclusion, so that a process, method, commodity or device that includes a list of the elements not only include these elements, but also include other elements that are not expressly listed, or include elements inherent to such a process, method, commodity or device. An element preceded by "includes a ..." does not exclude, without further restrictions, the existence of additional identical elements in the process, method, merchandise or device that includes the element.
[0138] One skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system or a computer program product. Therefore, the present invention can use a hardware-only embodiment, software-only embodiments or embodiments with a combination of software and hardware. In addition, the present invention may use a form of computer program product that is implemented on one or more storage media usable by a computer (including, without limitation, a disk memory, a CD-ROM and an optical memory) that include computer usable program code.
[0139] The present invention can be described in the general context of computer executable instructions executed by a computer, for example, a program module. In general, the program module includes a routine, a program, an object, a component, a structure of
Petition 870190058824, dated 06/25/2019, p. 186/192
50/50 dice, etc. to perform a specific task or implement a specific abstract data type. The present invention can also be practiced in distributed computing environments. In distributed computing environments, tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, the program module can be located on both the local and remote computer's storage media, including storage devices.
[0140] The embodiments in this specification are all progressively described. For the same or similar parts of the embodiments, see the embodiments. Each embodiment focuses on a difference from other embodiments. In particular, a system embodiment is basically similar to a method embodiment and is therefore briefly described. For related parts, see partial descriptions of the method's realization.
[0141] The foregoing descriptions are merely embodiments of the present invention and are not intended to limit the present invention. One skilled in the art can make various modifications and changes to the present invention. Any modification, equivalent substitution, improvement, etc., made within the spirit and principle of the present invention, must be within the scope of the claims of the present invention.

权利要求:
Claims (14)
[1]
Claims
1. METHOD FOR PROCESSING SERVICES, characterized by the fact that the method comprises:
receive, through a first trust protocol node and, through the use of a server comprised in the first trust protocol node, a service request sent by a client, in which the first trust protocol node comprises a plurality of servers and at least one service memory;
store the service request in the service memory comprised in the first trust protocol node; and send the service request to each second trust protocol node in a consensus network, so that each second trust protocol node stores the service request in a service memory comprised in the second trust protocol node after receiving the service request, wherein the second trusted protocol node comprises a plurality of servers and at least one service memory.
[2]
2. METHOD, according to claim 1, characterized by the fact that before receiving the service request, the method also comprises:
in response to the determination that a server on the first trust protocol node is online, send a server address to a registration center, so that the registration center sends the address to the client and each second protocol node of trust in the consensus network, or in response to the determination that the server on the first trust protocol node is offline, send an offline notification to delete an address from the server.
Petition 870190058824, dated 06/25/2019, p. 188/192
2/4
[3]
3. METHOD, according to claim 1, characterized by the fact that before sending the service request, the method also comprises:
obtain, through the first trust protocol node, addresses of the plurality of servers included in each second trust protocol node from a registration center.
[4]
4. METHOD, according to claim 3, characterized by the fact that the sending of the service request for each second trust protocol node in the consensus network comprises:
selecting an address from the addresses of the plurality of servers included in each second trust protocol node; and send the service request to a server corresponding to the address.
[5]
5. METHOD, according to claim 1, characterized by the fact that the storage of the service request in the service memory comprised in the first trust protocol node comprises:
perform valid verification on the service request; and store the service request in service memory in response to the determination that the service request is successful in valid verification.
[6]
6. METHOD, according to claim 5, characterized by the fact that it also comprises:
skip storing the service request in response to the determination that the service request was unsuccessful in valid verification.
[7]
7. METHOD, according to claim 1, characterized by the fact that it also comprises:
receive, through a customer, service information entered
Petition 870190058824, dated 06/25/2019, p. 189/192
3/4 by a user; and generate a corresponding service request based on the service information.
[8]
8. METHOD, according to claim 1, characterized by the fact that it also comprises:
selecting, through the first trust protocol node, a server from a plurality of servers included in the first trust protocol node;
obtain at least one service request from the service memory included in the first trust protocol node, using the server; and package at least one service request in a preprocessing block, using the selected server and sending the preprocessing block to each second trust protocol node in a consensus network, so that every second trust protocol node realizes service consensus in the preprocessing block, where the second trust protocol node comprises a plurality of servers and at least one service memory.
[9]
9. METHOD, according to claim 8, characterized by the fact that the first trust protocol node and the second trust protocol node each further comprise a scheduled task trigger.
[10]
10. METHOD, according to claim 9, characterized by the fact that the selection, through the first trust protocol node, of the server from the plurality of servers included in the first trust protocol node comprises:
detect, through the use of the scheduled task trigger, if a current moment satisfies a task trigger condition; and
Petition 870190058824, dated 06/25/2019, p. 190/192
4/4 in response to the detection that the task trigger condition is satisfied, select the server from the plurality of servers included in the first trust protocol node, using the scheduled task trigger.
[11]
11. METHOD, according to claim 1, characterized by the fact that it also comprises:
receive, a heartbeat detection message to the server;
determine whether a reply message is returned by the server;
in response to receiving no response message returned by the server comprised in the first trusted protocol node based on the heartbeat detection message after a specified time has elapsed, determine that the server is offline; and instruct the client and the other trusted protocol nodes in the consensus network to exclude the server address.
[12]
12. METHOD, according to claim 1, characterized by the fact that the server shares node configuration information comprising a point-to-point routing table, an asymmetric public key, an asymmetric private key and a node identity.
[13]
13. METHOD, according to claim 1, characterized by the fact that the service request is ordered from a plurality of service requests based on a predetermined ordering rule based on a hash algorithm.
[14]
14. DEVICE FOR PROCESSING SERVICES, characterized by the fact that the device comprises a plurality of modules configured to execute the method, as defined in any of claims 1 to 13.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112019013204A2|2019-12-10|service processing method and service processing device

---

BR112019020374B1|2022-01-25|Method, non-transient computer-readable storage media and system for blockchain consensus

---

RU2731331C1|2020-09-01|Consensus method and device based on blockchain

---

BR112019017409A2|2020-03-31|METHOD FOR BUSINESS VERIFICATION AND APPARATUS FOR BUSINESS VERIFICATION

---

BR112019013367A2|2019-12-31|consensus verification method and consensus verification device

---

US20190391971A1|2019-12-26|Technologies for providing attestation of function as a service flavors

---

BR112019013441A2|2019-12-31|data storage method and data storage device

---

ES2626655T3|2017-07-25|Failover of grouped clients

---

BR112019020197A2|2020-04-22|method and apparatus for processing transaction requests

---

BR112019012905A2|2019-12-03|method for submitting transaction information and device for submitting transaction information

---

BR112019014478A2|2020-05-26|METHOD FOR DETERMINING THE DATABASE STATUS AND DEVICE FOR DETERMINING THE DATABASE STATUS

---

US20150277930A1|2015-10-01|In-system provisioning of firmware for a hardware platform

---

US10146657B2|2018-12-04|Initialization trace of a computing device

---

US8943082B2|2015-01-27|Self-assignment of node identifier in a cluster system

---

US10073969B1|2018-09-11|File system metadata extension utilizable with object store

---

US10878096B2|2020-12-29|BIOS startup method and data processing method

---

BR112019009576A2|2019-10-22|data processing method and device

---

WO2018120810A1|2018-07-05|Method and system for solving data collision

---

GB2500348B|2019-08-21|Validation of access to a shared data record subject to read and write access by multiple requesters

---

WO2018233630A1|2018-12-27|Fault discovery

---

BR112019019871B1|2021-11-16|NON TRANSITIONAL STORAGE MEDIA READABLE BY COMPUTER, METHOD AND SYSTEM ASSOCIATED WITH A FIRST BLOCKCHAIN NUMBER OF A CONSENSUS NETWORK

---

US20220046014A1|2022-02-10|Techniques for device to device authentication

---

US20220070156A1|2022-03-03|Determining session duration for device authentication

---

BR112018074497B1|2021-11-30|METHOD TO PREVENT A SERVER FROM BEING ATTACKED AND DEVICE TO PREVENT A SERVER FROM BEING ATTACKED

---

BR112019019871A2|2020-04-22|consensus verification method and apparatus

同族专利:

---

公开号 | 公开日

---

KR102152556B1|2020-09-07|

---

US20200287987A1|2020-09-10|

---

CA3048737A1|2018-10-04|

---

KR20190093598A|2019-08-09|

---

JP2020508594A|2020-03-19|

---

PH12019501538A1|2020-03-16|

---

CN107395659A|2017-11-24|

---

US11057493B2|2021-07-06|

---

TW201837734A|2018-10-16|

---

RU2735096C1|2020-10-28|

---

WO2018177239A1|2018-10-04|

---

US20190342422A1|2019-11-07|

---

CN107395659B|2021-08-24|

---

AU2018243075B2|2020-06-18|

---

CN113766035A|2021-12-07|

---

US10681175B2|2020-06-09|

---

EP3547648A1|2019-10-02|

---

ZA201904230B|2021-05-26|

---

EP3547648B1|2021-07-07|

---

JP6773912B2|2020-10-21|

---

TWI686709B|2020-03-01|

---

AU2018243075A1|2019-07-11|

---

MX2019007812A|2019-09-05|

---

PH12019501538B1|2020-03-16|

---

US20210337045A1|2021-10-28|

---

EP3547648A4|2020-01-08|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US7886023B1|2000-01-21|2011-02-08|Cisco Technology, Inc.|Method and apparatus for a minimalist approach to implementing server selection|

---

US20050050227A1|2003-07-03|2005-03-03|Cascade Basic Research Corp.|Method and system for peer-to-peer directory services|

---

CN101635726B|2009-08-26|2012-07-04|中兴通讯股份有限公司|Service end of C/S architecture and service executing method and service executing system of client|

---

US10454997B2|2012-09-07|2019-10-22|Avigilon Corporation|Distributed physical security system|

---

US9519925B2|2013-08-01|2016-12-13|Omnibazaar, Inc.|Decentralized internet shopping marketplaces|

---

US10263836B2|2014-03-24|2019-04-16|Microsoft Technology Licensing, Llc|Identifying troubleshooting options for resolving network failures|

---

US10409827B2|2014-10-31|2019-09-10|21, Inc.|Digital currency mining circuitry having shared processing logic|

---

US10484168B2|2015-03-02|2019-11-19|Dell Products L.P.|Methods and systems for obfuscating data and computations defined in a secure distributed transaction ledger|

---

US20170048209A1|2015-07-14|2017-02-16|Fmr Llc|Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems|

---

US20170031676A1|2015-07-27|2017-02-02|Deja Vu Security, Llc|Blockchain computer data distribution|

---

KR101637854B1|2015-10-16|2016-07-08|주식회사 코인플러그|Certificate issuance system and method based on block chain, certificate authentication system and method based on block chain|

---

CN105488665A|2015-11-25|2016-04-13|布比（北京）网络技术有限公司|Decentralized transaction method|

---

CN105450757A|2015-12-02|2016-03-30|联动优势电子商务有限公司|Service management method and system|

---

CN113159948A|2016-01-24|2021-07-23|杭州复杂美科技有限公司|Block chain matching exchange|

---

KR101637868B1|2016-02-22|2016-07-08|주식회사 코인플러그|Financial institution document verification system that is based on the block chain|

---

CN106022681A|2016-05-13|2016-10-12|杭州云象网络技术有限公司|Logistics tracking method based on block chain|

---

CN106060036B|2016-05-26|2019-07-16|布比（北京）网络技术有限公司|Decentralization common recognition method and device|

---

US10713731B2|2016-07-22|2020-07-14|Nec Corporation|Method for secure ledger distribution and computer system using secure distributed ledger technology|

---

CN106384236B|2016-08-31|2019-07-16|江苏通付盾科技有限公司|Based on the ca authentication management method of block chain, apparatus and system|

---

KR101781583B1|2016-08-31|2017-09-27|서강대학교산학협력단|File management and search system based on block chain and file management and search method|

---

CN106357644B|2016-09-21|2019-07-12|江苏通付盾科技有限公司|Identity identifying method, system and server based on block chain network|

---

CN106385319B|2016-09-29|2020-11-27|江苏通付盾科技有限公司|Method and system for verifying information in block chain network|

---

CN106452785B|2016-09-29|2019-05-17|财付通支付科技有限公司|Block chain network, branch node and block chain network application method|

---

US11128603B2|2016-09-30|2021-09-21|Nec Corporation|Method and system for providing a transaction forwarding service in blockchain implementations|

---

CN106982203B|2017-01-06|2020-05-22|中国银联股份有限公司|Robust ATM network system based on block chain technology and information processing method thereof|

---

CN107196900B|2017-03-24|2020-04-24|创新先进技术有限公司|Consensus checking method and device|

---

CN107395659B|2017-03-28|2021-08-24|创新先进技术有限公司|Method and device for service acceptance and consensus|CN107395659B|2017-03-28|2021-08-24|创新先进技术有限公司|Method and device for service acceptance and consensus|

---

CN108009824A|2017-11-28|2018-05-08|北京博晨技术有限公司|Data common recognition method, apparatus and electronic equipment|

---

CN108537525B|2018-03-09|2020-06-09|阿里巴巴集团控股有限公司|Consensus verification method, device and equipment|

---

CN108769150B|2018-05-14|2021-11-12|百度在线网络技术（北京）有限公司|Data processing method and device of block chain network, cluster node and storage medium|

---

CN111030802B|2018-05-16|2020-12-29|腾讯科技（深圳）有限公司|Method, device and equipment for distributing calculation tasks of graph data and storage medium|

---

US11134120B2|2018-05-18|2021-09-28|Inveniam Capital Partners, Inc.|Load balancing in blockchain environments|

---

US11170366B2|2018-05-18|2021-11-09|Inveniam Capital Partners, Inc.|Private blockchain services|

---

CN108965379B|2018-05-29|2021-03-16|张迅|Resource scheduling device and method|

---

CN109192287A|2018-08-21|2019-01-11|中国联合网络通信集团有限公司|Hospital's hospital register method and device based on block chain|

---

CN109257427B|2018-09-26|2021-04-02|网宿科技股份有限公司|Service processing method and system based on block chain|

---

CN109547530B|2018-10-17|2021-07-27|北京瑞卓喜投科技发展有限公司|Region consensus method, system and equipment|

---

CN109286632B|2018-10-25|2021-01-15|中国信息通信研究院|Block chain-based big data authorization and evidence-storing method and system|

---

CN110020945B|2018-11-27|2020-10-30|创新先进技术有限公司|Data reading method and system based on multiple block chain networks|

---

CN110060152B|2018-11-27|2020-10-30|创新先进技术有限公司|Data reading method and system based on multiple block chain networks|

---

CN110060153B|2018-11-27|2020-11-17|创新先进技术有限公司|Data evidence storage method and system based on multiple block chain networks|

---

CN111224793B|2018-11-27|2021-06-01|华为技术有限公司|Data storage method and device, computer equipment and readable storage medium|

---

US10735464B2|2018-12-29|2020-08-04|Alibaba Group Holding Limited|System and method for detecting replay attack|

---

CN112215608A|2019-01-18|2021-01-12|创新先进技术有限公司|Data processing method and device|

---

CN109831425B|2019-01-25|2022-02-15|中国联合网络通信集团有限公司|Block chain consensus method, device, equipment and computer readable storage medium|

---

JP2020123188A|2019-01-31|2020-08-13|富士通株式会社|Communication device, communication program, and communication method|

---

CN110061856A|2019-03-07|2019-07-26|阿里巴巴集团控股有限公司|A kind of communication means based on block chain, device and electronic equipment|

---

CN110135194B|2019-05-20|2020-10-30|北京邮电大学|Block chain-based industrial internet digital object management method|

---

CN112181474A|2019-07-04|2021-01-05|北京新唐思创教育科技有限公司|Block chain service processing method, electronic device and computer storage medium|

---

CN110933166A|2019-11-27|2020-03-27|中国联合网络通信集团有限公司|Consensus platform, terminal, node and path selection method|

---

CN111464356B|2020-04-01|2021-11-05|腾讯科技（深圳）有限公司|Block consensus period switching method and device and computer equipment|

---

CN111786952A|2020-05-29|2020-10-16|中国银联股份有限公司|Consensus method, apparatus, device and medium for block chain system|

---

CN112416731B|2020-12-02|2021-07-30|腾讯科技（深圳）有限公司|Stability monitoring method and device applied to block chain system|

法律状态:
2021-04-06| B25A| Requested transfer of rights approved|Owner name: ADVANTAGEOUS NEW TECHNOLOGIES CO., LTD. (KY) |

---

2021-04-27| B25A| Requested transfer of rights approved|Owner name: ADVANCED NEW TECHNOLOGIES CO., LTD. (KY) |

---

2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|

---

2022-02-22| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

CN201710191462.XA|CN107395659B|2017-03-28|2017-03-28|Method and device for service acceptance and consensus|

---

PCT/CN2018/080461|WO2018177239A1|2017-03-28|2018-03-26|Service processing and consensus method and device|

---